If I call canOpenFile with a filename that does not contain the full path
e.g. -> canOpenFile("MyFile.txt",true)
it will return true, even if I have MyFile.txt open with another application (on Windows)
However, if I fully qualify the name
e.g. -> canOpenFile("c:\\temp\\MyFile.txt") it will correctly return false, when the file is open by another application.
If I do currentDirectory() the value I get is identical to the value I used to fully qualify the filename. In fact, I can do
strPath = currentDirectory()
strFullpath = strPath "/" "MyFile.txt"
canOpenFile(strFullpath,true) and it will correctly return false.
I can immediately follow that call with
canOpenFile("MyFile.txt" and it will incorrectly return true.
Anyone know what is going on?
Doorsbert - Wed Feb 04 06:30:18 EST 2009 |
|
Re: canOpenFile()
dpechacek - Wed Feb 04 08:44:28 EST 2009
I have the same behavior in 8.3 (you don't mention what version you're on). Sounds like a bug. But it's so far down the totem pole from being fixed, it won't even be looked at.
AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
|
|
Re: canOpenFile()
Doorsbert - Wed Feb 04 15:17:06 EST 2009 dpechacek - Wed Feb 04 08:44:28 EST 2009
I have the same behavior in 8.3 (you don't mention what version you're on). Sounds like a bug. But it's so far down the totem pole from being fixed, it won't even be looked at.
AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
|
|
Re: canOpenFile()
llandale - Mon Feb 23 16:55:07 EST 2009
You're in luck, turns out I just last week did some work with canOpenFile(). When parameter 'forWrite' is true, the function returns true when <1> the file doesn't exist, and <2> it does exist but is not currently open by a program that 'locks' files, such as MS-Word.
Associating a non-path file name in 'canOpenFile' with 'currentDirectory()' is a reasonable one, but not necissarily correct. I strongly suspect that your 'MyFile.txt' is not the same as your file 'c:\\Temp\\MyFile.txt' even when the currentDirectory() is 'c:\\Temp\\'. You can probably check that by either <1> proceeding to open the file, or perhaps <2> just displaying it with 'system("Notepad.exe MyFile.txt")'.
|
|
Re: canOpenFile()
Doorsbert - Thu Mar 05 18:58:08 EST 2009 llandale - Mon Feb 23 16:55:07 EST 2009
You're in luck, turns out I just last week did some work with canOpenFile(). When parameter 'forWrite' is true, the function returns true when <1> the file doesn't exist, and <2> it does exist but is not currently open by a program that 'locks' files, such as MS-Word.
Associating a non-path file name in 'canOpenFile' with 'currentDirectory()' is a reasonable one, but not necissarily correct. I strongly suspect that your 'MyFile.txt' is not the same as your file 'c:\\Temp\\MyFile.txt' even when the currentDirectory() is 'c:\\Temp\\'. You can probably check that by either <1> proceeding to open the file, or perhaps <2> just displaying it with 'system("Notepad.exe MyFile.txt")'.
Where does DOORS DXL expect a non-path file name to be?
"I strongly suspect that your 'MyFile.txt' is not the same as your file 'c:\\Temp\\MyFile.txt' even when the currentDirectory() is 'c:\\Temp\\'. "
The question is, what is "MyFile.txt" to canOpenFile()? It doesn't look in the current directory - as it should. What directory have the DOORS DXL developers chosen to append to a non-path filename? Or does their software ignore any file path that is not full and just automatically assume that it can be written? What would it take to get someone to look at the canOpenFile() code?
"You can probably check that by either <1> proceeding to open the file, or perhaps <2> just displaying it with 'system("Notepad.exe MyFile.txt")'."
If I run "Notepad.exe somefile" and do a Save As - it defaults to saving it in the DOORS client installation directory. However, canOpenFile() still did not squawk when I locked at file in that directory and ranCanOpenFile() without a full path.
|
|
Re: canOpenFile()
Tony_Goodman - Fri Mar 06 09:02:15 EST 2009 Doorsbert - Thu Mar 05 18:58:08 EST 2009
"Associating a non-path file name in 'canOpenFile' with 'currentDirectory()' is a reasonable one, but not necissarily correct."
Where does DOORS DXL expect a non-path file name to be?
"I strongly suspect that your 'MyFile.txt' is not the same as your file 'c:\\Temp\\MyFile.txt' even when the currentDirectory() is 'c:\\Temp\\'. "
The question is, what is "MyFile.txt" to canOpenFile()? It doesn't look in the current directory - as it should. What directory have the DOORS DXL developers chosen to append to a non-path filename? Or does their software ignore any file path that is not full and just automatically assume that it can be written? What would it take to get someone to look at the canOpenFile() code?
"You can probably check that by either <1> proceeding to open the file, or perhaps <2> just displaying it with 'system("Notepad.exe MyFile.txt")'."
If I run "Notepad.exe somefile" and do a Save As - it defaults to saving it in the DOORS client installation directory. However, canOpenFile() still did not squawk when I locked at file in that directory and ranCanOpenFile() without a full path.
|
|
Re: canOpenFile()
dpechacek - Fri Mar 06 09:35:42 EST 2009 Tony_Goodman - Fri Mar 06 09:02:15 EST 2009
For me the file gets created in "My Documents".
AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
|
|
Re: canOpenFile()
llandale - Sat Mar 07 15:10:41 EST 2009 Doorsbert - Thu Mar 05 18:58:08 EST 2009
"Associating a non-path file name in 'canOpenFile' with 'currentDirectory()' is a reasonable one, but not necissarily correct."
Where does DOORS DXL expect a non-path file name to be?
"I strongly suspect that your 'MyFile.txt' is not the same as your file 'c:\\Temp\\MyFile.txt' even when the currentDirectory() is 'c:\\Temp\\'. "
The question is, what is "MyFile.txt" to canOpenFile()? It doesn't look in the current directory - as it should. What directory have the DOORS DXL developers chosen to append to a non-path filename? Or does their software ignore any file path that is not full and just automatically assume that it can be written? What would it take to get someone to look at the canOpenFile() code?
"You can probably check that by either <1> proceeding to open the file, or perhaps <2> just displaying it with 'system("Notepad.exe MyFile.txt")'."
If I run "Notepad.exe somefile" and do a Save As - it defaults to saving it in the DOORS client installation directory. However, canOpenFile() still did not squawk when I locked at file in that directory and ranCanOpenFile() without a full path.
currentDirectory() appears to be the same one that's defined in the 'Start in' folder of the DOORS icon used to initiate DOORS; typically "...\bin". I tried, but couldn't find a way to change the value of currentDirecory() in DOORS, by playing with Windows Explorer. Don't see anything in the doors.exe.
For me, using unqualified names when 'write'ing a file, created it in the currentDirectory(), even when I changed it in the Icon. Using <system("notepad.exe " NameFile)> displays the file, but save-as shows some other location. That save-as location, STRANGELY, for me appears to be the last folder I used when reaching onto my client from within Citrix. E'Gads!! what's going on...
I see no mechanism for querying a 'Stat' or 'Stream' variable for the full name of the corresponding file. Ugh.
Anyway, the morale of the story appears to be: use fully qualified names when dealing with Windows files.
|
|